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(54) Abstract Title 

Secure distribution of session keys to a chain of network nodes 

(57) A chain of nodes 14, 22, 26 recursively constructs 
steps 94, 96, 98 and presents step 100 a nested request to 
the authentication server 18, which Includes a sealed or 
encrypted portion. The nested request includes a request 
from each of the nodes in the chain requiring a session 
key to communicate with a neighboring node. The 
authentication server recursively unravels the request and 
recursively prepares a response that includes a session 
key for each node that submitted a request Figs. 5, 6, 7. 
The response traverses the chain of nodes in the reverse 
order taken by the nested request to reach the 
authentication server. Each node receiving the response 
extracts the portion of the response directed to that node, 
and forwards the remainder of the response, if any, to the 
next node in the chain Fig 8. Thus, with a single traversal 
of the chain of nodes each node receives at least one 
session key. The forward and reverse protocols easily 
generalize for any number of nodes in the chain. The 
protocols can employ one-way hash functions to seal 
requests and responses and to encode/encipher session 
keys. Portions of the response may be encrypted using the 
session keys. 
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A SYSTEM AND METHOD FOR SECURE DISTRIBUTION OF SESSION KEYS TO 
A CHAIN OF COMPUTER SYSTEM NODES IN A NETWORK 



This invention relates generally to client-server computer networks. More 
specifically, the invention relates to a system and method for securely distributing 
information among clients and servers in a network. 

Authentication of computer systems plays an important role in data communications 
over modern networks. With the rapidly increasing reliance on the electronic highways to 
convey sensitive data comes the greater need for increased security for such data 
transmissions. Computer systems need to be mutually assured of the identities of those 
computer systems with which they exchange information. Further, these computer systems 
need the assurance that the information in these communications has not been altered during 
transmission. These needs have led to various techniques that enable computer systems to 
exchange information securely. 

One common authentication technique entails presenting a challenge to the computer 
system to which the computer system must correctly respond in order to gain permission for 
subsequent communication. Other authentication techniques involve encryption methods. 
Generally, there are two main types of encryption methods: asymmetric encryption and 
symmetric encryption. Asymmetric encryption methods use two different keys, one to 
encrypt the communication and the other to decrypt the communication. For example, 
public-key encryption is an asymmetric encryption technique in which one computer system 
encrypts a communication using a public key and another computer system decrypts the 
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communication using a private key known only to that other computer system. In contrast, 
symmetric encryption uses one key for both encryption and decryption. Some authentication 
techniques combine asymmetric and symmetric encryption methods. One exemplary 
technique is to use public key encryption to distribute a session key to a pair of computer 
systems that these computer systems then use with symmetric encryption algorithms to 
exchange encrypted data communications. 

An important factor to be considered when using encryption algorithms, however, is 
that some countries limit the key size for encryption within exported computer and software 
products. It is understood by those skilled in the art that such encryption algorithms, when 
constrained by the key size, may be broken. 

Summary of the Invention 

According to one aspect of the present invention, in a network including a first node, 
a second node, and a third node, there is provided a method for securely delivering digital 
information to the first node from the third node by way of the second node, the method 
comprising the steps of: 

receiving a request at the third node from the first node; 

generating digital information in response to the request; 

operating on the request and the digital information to produce a first data structure, 
the first data structure including a representation of the digital information; 

operating on the request and the first data structure to produce a second data structure, 
the second data structure including the first data structure; and 

transmitting the second data structure to the second node. 
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According to another aspect of the invention, in a network including a client node and 
an authentication server node, there is provided a method for securely delivering a session 
key to the client node from the authentication server node in response to a request from the 
client node, the method comprising the steps of: 

sealing plaintext using the session key; 

encoding the session key using a key shared with the client node; and 
transmitting a data structure to the client node that includes the encoded session key 
and the sealed plaintext. 

According to another aspect of the invention there is provided a system for securely 
distributing a session key by way of a network, the network including a first node 
transmitting a request to obtain the session key and a second node in communication with the 
first node, the system comprising: 

a third node in communication with the second node and receiving the request by way 
of the second node, the third node including: 

a processor generating (1) a first data structure by operating on the request and the 
session key, the first data structure including a representation of the session key, and (2) 
generating a second data structure by operating on the request and the first data structure, the 
second data structure including the first data structure; and 

a network interface coupled to the processor for transmitting the second data structure 
to the second node over the network. 

In one embodiment, the invention features a method for securely delivering digital 
information to the first node from the third node by way of the second node. The method 
includes receiving a request at the third node from the first node. In response to the request, 

3 



.2345620A_I_> 



digital information is generated. The request and the digital information are then operated on 
to produce a first data structure. The first data structure includes a representation of the 
digital information. The request and the first data structure are then operated on to produce a 
second data structure, with the second data structure including the first data structure. The 
second data structure is transmitted to the second node. 

In one embodiment, the digital information includes a session key for the first node to 
use when communicating with the second node. The session key is encoded using a key 
shared exclusively with the first node to conceal the session key within the first data 
structure. Also, the session key can be used to seal a portion of the first data structure. A 
second session key can be generated for the second node to use in communications with the 
first node. This second session key can be used to seal a portion of the second data structure 
containing the first data structure. Also, the second session key can be encoded using a key 
shared exclusively with the second node. The second data structure includes the encoded 
second session key. 

In one embodiment, the invention features a method for securely delivering a session 
key to a client node from an authentication server node in response to a request from the 
client node. The method includes sealing plaintext using the session key. The session key is 
encoded using a key shared with the client node. A data structure including the encoded 
session key and the sealed plaintext is transmitted to the client node. At the client node, the 
data structure can be extracted. The encoded session key is decoded using the shared key, 
and the seal of the plaintext checked using the decoded session key. The plaintext can be 
used to authenticate that the session key originated from the authentication server, that the 
decoded session key is unaltered during transmission from the authentication server, and that 
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the data structure is a current response from the authentication server to the request from the 
client node. 

In one embodiment, the invention features a system for securely distributing a session 
key by way of a network. The network includes a first node transmitting a request to obtain 
the session key and a second node in communication with the first node. The system also 
includes a third node in communication with the second node for receiving the request by 
way of the second node. The third node has a processor that generates a first data structure 
by operating on the request and the session key. The resulting first data structure includes a 
representation of the session key. The processor also generates a second data structure by 
operating on the request and the first data structure. The second data structure includes the 
first data structure. 

Some embodiments of the invention will now be described in more detail with 
reference to the accompanying drawings, in which: 

Fig. 1 is a diagram of an embodiment of a client node in communication with an 
authentication server node over a network; 

Fig. 2 is a diagram of an embodiment of functional components within each computer 

node; 

Fig. 3 is a diagram showing two exemplary forward flows of requests from the client 
node through two intermediate nodes to the authentication server node; 

Fig. 4 is a flow chart and block diagram representation of an embodiment of a process 
by which embedded requests are generated; 

Fig. 5 is a flow chart representation of an embodiment of a process by which the 
authentication server processes the embedded requests; 
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Fig. 6 is a diagram showing an exemplary return flow of responses from the 
authentication server node to the client node by way of the first and second intermediate 
nodes; 

Figs. 7 A and 7B provide a flow chart representation of an embodiment of a process 
by which the authentication server generates a response having at least one session key for 
each node in the chain of nodes; and 

Fig. 8 is a flow chart representation of an embodiment of a process by which each 
node receiving a response extracts at least one session key from that response. 

Fig. 1 shows an exemplary client-server system 2 embodying the principles of the 
invention. The client-server system 2 includes a computer system (client node A) 14 in 
communication with another computer system (authentication server node S) 18 over a 
network: 10 through a first and a second intermediate computer systems (intermediate nodes 
B and C) 22 and 26, respectively. It is to be understood that the system 2 can include any 
number of additional client, intermediate, and server nodes. Some of such intermediate 
nodes can merely forward information without participating in the authentication process. 
The network 10 can be, for example, a wide area network (WAN) or a local area network 
(LAN), an international network of networks, such as the Internet and the World Wide Web, 
or a network within a single organizational entity, called an Intranet. 

Fig. 2 shows functional components of an exemplary embodiment of the each node 
14, 18, 22, and 26. Each node 14, 18, 22, and 26 can be any conventional personal computer, 
workstation, network terminal, mini-computer, or mainframe computer. Each can include a 
processor 46, memory 50 for storing data and software programs, and I/O devices 54 (e.g., a 
keyboard and/or a mouse) in communication by way of a signal bus 62. Each node 1 4, 1 8, 
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22, 26 also includes a network interface 58 for communicating with the network 10. Stored 
in the memory 50 of each node are software routines for performing the authentication 
protocol of the invention as described below. These software routines (1) generate 
authentication requests, (2) evaluate authentication requests, (3) generate responses to 
authentication requests, and (4) evaluate responses. The processor 46 of each node executes 
the appropriate software routines to effectuate a forward flow (i.e., toward the server S 1 8) of 
authentication requests and a return flow (i.e., away from the server S 18) of responses as 
described below. 

Referring again to Fig. 1, two exemplary communication paths traverse the network 
10 from the client node A 14 to the authentication server node S 18. Each communication 
path can be represented as a "chain of nodes." A first chain of nodes includes the client node 
A 14, the first intermediate node B 22, and the authentication server node S 18. The first 
intermediate node B 22 is in communication with the client node A 14 by way of the 
communication link 30 and with the authentication server node S 1 8 by way of the 
communication link 34. 

A second exemplary chain of nodes includes the client node A 14, the first 
intermediate node B 22, the second intermediate node C 26, and the authentication server 
node S 1 8. The first intermediate node B 22 is in communication with the client node A 14 
by way of communication link 30 and with the second intermediate node C 26 by way of 
communication link 38. The second intermediate node C 26 is also in communication with 
the authentication server node S 18 by way of a communication link 42. The two chains of 
nodes are merely exemplary; a chain of nodes can have any number of intermediate nodes 
between the client node A 14 and the authentication server node S 18 that employ the 
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authentication protocol. Other embodiments include intermediate nodes that may not seek 
authentication or session keys, and therefore do not use the authentication protocol, but rather 
operate in the chain of nodes to forward requests and responses to the next neighboring node 
in the chain. 

The client node A 14 initiates authentication requests. For example, a user of the 
client node A 14 can submit a digital signature to approve a transaction. The first 
intermediate node B 22 can be a client-server node. Examples of intermediate nodes include 
a counter signer for approving financial transactions exceeding a dollar amount limit, a 
corporate signer for validating the signature of the client node A 14, a sacrificial server 
disposed between the two firewalls, and a business process server in front of a back end 
database server. 

Each node 14, 1 8, 22, 26 can function in the network 10 in the capacity of a client 
node, an intermediate node, or an authentication server depending upon the position of that 
node in a chain of nodes. For example, the client node A 14 and the authentication server 
node S 18 can function as an intermediate node when that node 14 or 18 receives a request to 
be forwarded to another authentication server. Each intermediate node 22, 26 and the 
authentication server node S 18 can operate as a client intermediate node 22 by initiating an 
authentication request. The client node A 14 and each intermediate node 22, 26 can function 
in the role of an authentication server. 

The authentication protocol assumes that each node 14, 22, and 26 shares a secret key 
exclusively with the authentication server 18. In the following description, the key shared by 
the client node A 14 and the authentication server node S 18 is referred to as Ka, by the first 
intermediate node B 22 and the authentication server node S 18 is Kfc, and by the second 
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intermediate node C 26 and the authentication server node S 18 is Kc. The client node A 14 
and each intermediate node 22, 26 trusts the authentication server node S 1 8. That is, each 
node 14, 22, 26 accepts that the authentication server 18 correctly performs the function of 
identifying the nodes 1 4, 22, 26 by way of the secret keys that the server node S 1 8 shares 
with each node 14, 22, 26 

In the example shown, the nodes 14, 18, 22, 26 communicate using an authentication 
protocol in accordance with the principles of the invention. When used between nodes 
needing authentication, the authentication protocol operates to provide authentication 
between pairs of nodes, in a chain of nodes in the client-server system 2. Authentication 
occurs at various points in the protocol. First, each node receiving a message is assured of 
the identity of the node transmitting the message so that communications are not conducted 
with an impostor. Second, the protocol assures that the contents of the received message are 
authentic in that such contents have not be altered during transmission from the transmitting 
node to the receiving node. Third, the protocol assures the timeliness of the received 
message in that the message is received in response to a particular request and is not an 
attempt by an intruder to mimic a previous authentic communication. 

The authentication protocol also produces session keys for each pair of nodes as 
described below. Each session key can be a randomly generated value used for signing 
messages or encryption. Only nodes possessing the same session key for decoding the 
encryption can understand encrypted communications. Consequently, two or more nodes 
having the same session key can communicate privately. Session keys exist only for the 
duration of a particular session (or conversation). Accordingly, nodes can request session 
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keys as needed and subsequently destroy the session keys when the conversations are 
complete. 

Fig. 3 shows an exemplary chain of nodes illustrating a bi-directional flow of requests 
and responses. Requests pass to and responses pass from the authentication server node S 18. 
In brief overview, in one embodiment the client node A 14 generates a request for 
authentication and for obtaining a session key and transmits the request to the first 
intermediate node B 22. The request includes both plain text and sealed text. The first 
intermediate node B 22 adds its authentication information to the original request from the 
client node A 1 4 to generate a new authentication request and forwards the new 
authentication request to the second intermediate node C 26. Nested within the new 
authentication request is the original request from the client node A 14. 

The second intermediate node C 26 adds information to the request from the first 
inteimediate node B 22 to generate a second new authentication request and forwards the 
second new authentication request to the authentication server node S 1 8. Nested within the 
second new authentication request is the authentication request received from the first 
intermediate node B 22, within which is the original request from the client node A 14. The 
process can be repeated for as many intermediate nodes as are in the chain of nodes. The 
authentication server node S 18 receives a final request containing the nested requests of each 
intermediate node 22, 26 and the client node A 1 4. 

According to the principles of the invention, the authentication server node S 18 
recursively unravels the final request containing the nested requests to determine those nodes 
in the chain that are expecting a response. From the unraveling of the final request, the 
authentication server node S 18 determines an order in which to recursively nest responses to 
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each of the nodes in the chain within a final response. Consequently, the final response 
includes a response to each node in the chain, and each response includes at least one session 
key for that respective node in the chain. The individual responses are nested within each 
other, as described further below, with the response to the client node A 14 being most 
deeply nested within the final response. 

In the embodiment shown, the authentication server node S 18 transmits the final 
response to the second intermediate node C 26. Each node in the chain extracts and 
authenticates at least one session key directed to that node from the final response, and 
forwards the remainder of the response to the next node in the chain away from the server 1 8. 
Accordingly, with the final response the authentication server node S 18 delivers session keys 
and provides authentication to each node in a chain. It is to be understood that the principles 
of the invention can be extended to securely transmit any type of information and not just 
session keys. Also, the protocol can extend to any number of nodes in a chain. An 
advantage gained by the authentication protocol of the invention is that each node in the 
chain does not need knowledge of the global behavior of the system 2 to achieve 
authentication and obtain a session key. 

In one embodiment, the authentication server node S 1 8 can deliver the same session 
key to pairs of adjacent nodes, such as, for example, the client node A 14 and the first 
intermediate node B 22. In other embodiments, the authentication server node S 18 can 
deliver the same session key to nodes that are separated by one or more intermediate nodes, 
e.g., the client node A 14 and the second intermediate node C 26. 



11 



2345620A 1 > 



Generation of an Authenticatio n Request 

Fig. 4 presents a flowchart and a block diagram illustrating an embodiment of an 
exemplary process by which the client node A 14 and each intermediate node 22, 26 generate 
and forward a recursively constructed final request to the authentication server node S 1 8. 
The client node A 14 initiates (step 94) an authentication request RQSTa 15. In the 
embodiment shown, RQSTa 15 includes a plaintext portion 72 and a sealed version 74 of the 
plaintext portion 72. The sealed version 74 is sealed by the client node A 14 using the shared 
key Ka as described previously and below. Throughout the specification, the sealing of data 
(here, a copy of the plaintext portion 72) is accomplished by applying a one-way hash- 
function to the data. One-way hash functions take variable-length input strings and produce 
fixed-length output strings. An attribute of such a one-way hash function is that 
reconstructing the input string from the output string is computationally difficult. Examples 
of one-way hash functions that can be used to practice the invention are well known in the 
art. 

A purpose of the one-way hash function is to guarantee the integrity of the message 
data. For example, when the server S 18 receives the plaintext portion 72 and the sealed 
version 74 from the client node A 14, the server S 18 can apply the one-way hash function to 
the plaintext portion 72 using the secret key Ka shared with the client node A 14. Thus, the 
server S 18 produces another sealed version of the plaintext portion 72, which the server S 18 
can compare with the sealed version 74 received from the client node A 14. A match 
between the sealed versions indicates that the integrity of the data was maintained during the 
transmission from the client node A 14 to the server node S 1 8. Sealing can be accomplished 
by employing other techniques (e.g., encryption algorithms). Accordingly, any reference 
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hereafter to sealing or sealed data contemplates any method, e.g., a one-way hash fiinction or 
an encryption algorithm, capable of producing the seal. 

The plaintext portion 72 is a bit string of data that includes a nonce Na combined with 
a message Ma. The nonce Na is a value randomly generated by the client node A 14 that 
uniquely identifies the authentication request at client node A 14. Client node A 14 stores the 
nonce Na in memory for later reference. The message Ma is a bit string that identifies the 
two nodes for which a session key is sought, here client node A 14 and the intermediate node 
B 22. An exemplary notation for the message Ma is (A, B). In one embodiment, the nonce 
Na is concatenated to the end of the message Ma such that an exemplary notation for the 
plaintext portion 72 is 

(Ma, Na). 

The sealed version 74 is a sealed bit string produced from the data Ma, Na in the 
plaintext portion 72 and is referred to as message digest, Da. The client node A 14 can 
produce the message digest Da by computing a one-way hash function of the plaintext data 
Na and Ma using the key, Ka, shared exclusively with the authentication server node S 18. 
Before generating the message digest Da, the client node A 14 inserts a copy of the key Ka 
into a copy of the plaintext portion 72. The key Ka can be placed in front of the copy of the 
plaintext portion 72 to add randomness to the message and/or at the end of the copy of the 
plaintext portion 72 to prevent the digest Da from being extended. Although the invention 
does not require placement at both the front and at the end, performance of both strengthens 
the protection of the message digest Da. An exemplary notation for the message digest Da 
is: 

<Ma, Na>Ka. 
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To form RQSTa 15, the plaintext portion 72 and sealed version 74 are combined. In 
one embodiment, the sealed version 74 is concatenated to the end of the plaintext portion 72. 
An exemplary notation for the RQSTa 15 is: 

(Ma, Na), Da or 

(Ma, Na), <Ma, Na>Ka. 
Note that the parenthesis "( ) " braces "< >," spaces and commas are for notation purposes 
only and are not part of the string of data that form RQSTa 15 (or any other bit string of 
data). 

The client node A 14 transmits (step 96) the RQSTa 15 to the intermediate node B 22 
by way of communication link 30. Responsive to the RQSTa 15, the intermediate node B 22 
produces (step 98) a new request RQST6 16. Again, the RQSTZ> 16 includes a plaintext 
portion 78 and a sealed version 80 of the plaintext portion 78 as described previously with 
respect to RQSTa 15. The plaintext and sealed portions 78, 80 each include the plaintext 
portion 72 and the sealed version 74 of RQSTa 15. 

Specifically, the plaintext portion 78 is a bit string that includes a message, Mb, and a 
nonce Nft generated by intermediate node B 22, and the RQSTa 15 is received from client 
node A 14. Intermediate node B 22 stores the nonce Nfc in memory for later reference when 
verifying a response from server node S 18. An exemplary notation for the plaintext portion 
78 is 

(Mfe, N6), (Ma, Na), <Ma, Na> Ka or 
(M&, Nb, RQSTa). 

Note that the plaintext portion 78 includes sealed data, which come from RQSTa 15. 
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In this embodiment, intermediate node B 22 concatenates the nonce No to the 
message Mb, and RQSTa 15 to the end of the nonce N&. In other embodiments, the order 
may differ. As with message Ma, the message Mb includes the identities of the nodes for 
which a session key is requested. Thus, if the session key is required between intermediate 
node B 22 and intermediate node C 26, the message Mb is (B, C). 

Similar to previous RQSTa 15, the sealed version 80 is an sealed bit string 
representing the data in the plaintext portion 78. In one embodiment, the sealed version 80 
includes a message digest, Db, produced by computing a one-way hash function of the data 
components Mb, N6, and RQSTa 15 using the key, Kb, shared exclusively by nodes B and S. 
An exemplary notation for the sealed version 80, which is the message digest Db, is 

<Mb, N5, Ma, Na, <Ma, Na> Ka> Kb or 

<Mb, Nb, RQSTa>K6. 

In step 98, the intermediate node B 22 generates the new request RQSTo 16 as a 
combination of the plaintext portion 78 and the sealed version 80. In one embodiment, the 
sealed version 80 is concatenated to the end of the plaintext portion 78 as described 
previously and therefore an exemplary notation for the RQSTb 16 is 

(Mb, N6, RQSTa), <Mb, No, RQSTa>K&, 

in which the RQSTa 15 is recursively nested within the RQST6 16. Expanded notation for 
RQSTA is: 

(Mb, No, (Ma, Na), <Ma, Na>Ka), <Mb, Na, (Ma, Na), <Ma, Na>Ka>K6. 

Similarly as for client node A 14 and intermediate node B 22, intermediate node C 26 
produces a new request RQSTc 17. RQSTc 17 includes a plaintext portion 86 and a sealed 
version 88 of the plaintext portion 86. 
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The plaintext portion 86 is a bit string that includes a message Mc, a nonce Nc, and 
the RQST6 16. Exemplary notation here for Mc is (C, S), and for the plaintext portion 86, 
(Mc, Nc, RQST6). Intermediate node C 26 stores the nonce Nc in memory for use when 
verifying a response from server node S 1 8. Again, the message Mc includes the identities of 
the two intermediate nodes for which a session key is sought. 

The sealed version 88 is a sealed bit string representing the data, Mc, Nc, and RQST& 
16, in the plaintext portion 86. In one embodiment, sealed version 88 includes a message 
digest, Dc, produced by computing a one-way hash function of the data components Mc, Nc, 
and RQST6 16 using the key Kc. Kc is the key shared exclusively between intermediate 
node C 26 and server node S 1 8. An exemplary notation for the message digest Dc is 

<Mc, Nc, RQSTi»Kc. 

In step 98, the intermediate node C 26 generates the new request RQSTc 1 7 as a 
combination of the plaintext portion 86 and the sealed version 88, for example, by 
concatenating the sealed version 88 to the end of the plaintext portion 86. An exemplary 
notation for RQSTc 17 is 

(Mc, Nc, RQST&), <Mc, Nc, RQST£>Kc. 
in which the RQST& 16 is recursively nested within the RQSTc 17. Expanded notation for 
RQSTc is: 

(Mc, Nc, (M6, NZ>, (Ma, Na), <Ma, Na>Ka), <Mb 9 Nfe, (Ma, Na), <Ma, Na>Ka> Kb) 
<Mc, Nc,(M6, Nfr, (Ma, Na), <Ma, Na>Ka), <M6, N£, (Ma, Na), <Ma, Na>Ka> Kb >Kc. 

The form of the request generated at each node X requesting a session key for communication with 
node X+l generalizes to: 

RQSTx = (X, X+l , Nx, RQSTjc-/), <X, X+l , Nx, RQSTx-i>Kx, 
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where X-l is the identity of the previous node, if any, and RQSTx-7 is the request given by the 
previous node X-l for requesting a session key for communication between node X-l and X. 
Evaluating the Authentication Request 

In step 100, the last intermediate node in the chain of nodes transmits the final request 
to server node S 1 8. For illustration purposes, the last intermediate node in the example 
shown is intermediate node C 26, and the final request is RQSTc 17. Accordingly, as 
described above, the final request RQSTc 17 received by server node S 18 can be expressed 
as: 

(Mc, Nc, RQST&) <Mc, Nc, RQSTfc>Kc, 
where the plaintext portion 86 is 

(Mc, Nc, RQS170, 
and the sealed version 88 of the plaintext portion 86 is 

<Mc, Nc, RQSTfr>Kc. 

Fig. 5 shows an exemplary process by which the server node S 1 8 recursively 
unravels RQSTc 17 to (1) authenticate each node in the chain of nodes and (2) authenticate 
the integrity of the data in each request within RQSTc 17 (i.e., RQSTA 16 and RQSTa 15). 
The server node S 1 8 uses (step 104) the key shared with intermediate node C 26, Kc, to 
determine the message digest Dc. From the digest Dc, the server node S 18 extracts the data 
Mc, Nc, and RQST6 17 from the sealed version 88. 

In step 108, server node S 1 8 compares the extracted data, Mc, Nc, and RQST£ 16, 
with the data Mc, Nc, and RQST6 1 6 in the plaintext portion 86. If the extracted data match 
the plaintext data, the server node S 1 8 knows that intermediate node C 26 is the sender of 
the RQSTc 1 7 because, other than server node S 1 8, only intermediate node C 26 knows the 
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shared key Kc used to create the sealed version 88. Server node S 18 therefore also knows 
that the data Mc, Nc, and RQST6 16 are unaltered during the transmission from intermediate 
node C 26 because the extracted and the plaintext data are the same. If the extracted data do 
not match the plaintext data, the final request RQSTc 17 is invalid. The server node S 1 8 can 
then ignore such a request. 

If RQSTc 17 is determined to be valid, server node S 18 then evaluates RQST£> 16, 

which can be expressed as: 

(Mb, Nfc, RQSTa), <Mb, Nd, RQSTo>Kfc. 
The plaintext portion 78 is therefore 

(Mb, Nb, RQSTa) 
and the sealed version 80 of the plaintext portion 78 is 

Db or 

<Mb, Ni», RQSTa>K6. 

Server node S 18 then uses Kb to extract (step 104) the data Mb, N6, and RQSTa 15 from the 
sealed version 80 and again compares (step 108) the extracted data with the data Mb, Nfc, and 
RQSTa 15 of the plaintext portion 78. 

In step 1 12, the extracted data are compared with the plaintext data components and if 
the components match, intermediate node B 22 is the sender of the RQST* 16 because only 
nodes B and S know the shared key Kb used to create the sealed version 80. Again, this 
match shows that the data Mb, N6, and RQSTa 15 are unchanged during the transmission 
from intermediate node B 22 to server node S 18. In one embodiment, if the extracted data 
do not match the plaintext data, server node S 1 8 can ignore the request RQSTc 17. In other 
embodiments, the server node S 18 can process valid portions of RQSTc. 
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If RQST6 is valid, the above-described process is repeated by server node S 1 8 with 
respect to RQSTa 15. 
Return Protocol 

Fig. 6 shows general operation of the client server system 2 in the return direction 
from server node S 18 to client node A 14 through nodes C and B, 26 and 22, respectively. 
Generally, server node S 18 produces a full response, e.g., RPNSEc 19, to a valid final 
request, e.g., RQSTc 17 described previously. The full response includes a response for each 
node in the chain of nodes requesting a session key. Each response contains the session key 
or keys intended for that node. Each response is also embedded within a response to a 
previous node as described below. As shown, RPNSEc 19 includes RPNSE6 20, and 
RPNSE6 20 includes RPNSEa 21. 

These responses traverse the chain of nodes in the reverse order by which the final 
request RQSTc 17 reached server node S 18. For example, intermediate node C 26 receives a 
response to its request for a session key before intermediate node B 22 receives its response 
to its request for a session key. As such, intermediate node C 26 removes that portion of the 
response RPNSEc 19 that is intended for intermediate node C 26 and forwards the remainder 
of the response, RPNSEfc 20, to intermediate node B 22. Likewise, intermediate node B 22 
extracts that portion of the response intended for intermediate node B 22 and forwards the 
remainder of the response, RPNSEa 21, to client node A 14. Thus, by this single traversal of 
the chain of nodes, server node S 18 can securely deliver at least one session key to each 
node in the chain. 
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Generation of the Response 

Figs. 7A and 7B shows an exemplary process by which server node S 18 produces the 
complete response RPNSEc 1 9. Server node S 1 8 generates RPNSEc 19 using session keys 
intended for the respective nodes such that each node in the chain can access only those 
session keys intended for that node. 
Generating RPNSEa 

Because of the recursive nesting of responses, the response intended for client node A 
14, RPNSEa 21 , is the most deeply nested response within the full response, RPNSEc 19. 
Accordingly, server node S 18 can construct RPNSEc 19 starting with RPNSEa 21 . In step 
120, server node S 18 generates plaintext intended for client node A 14. The plaintext can 
include a response message Kab and one or more nonces. Kab includes the identities of the 
two nodes for which the session key is intended, here nodes A and B. An exemplary notation 
for Rab is (A, B). In one embodiment, the plaintext includes nonces Na and No, which are 
the same nonces as Na and No sent to server node S 18 in the request RQSTc 17. Including 
the nonce Na in RPNSEa 21 enables client node A 14 to determine that RPNSEa 21 is 
current. Client node A 14 can determine from the nonce Na that the RPNSEa 21 is a 
response from server node S 18 to a current outstanding request and not a unauthorized 
replication of a valid, previous communication between nodes A and S. In one embodiment, 
server node S 18 concatenates the nonces to the end of the response message Kab, which can 
be expressed as: 

(Rao,Na,No). 

The server node S 18 generates (step 124) a sealed version of the plaintext data (Rao, 
Na, No). In one embodiment, the sealed version includes a message digest Dra produced by 
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computing a one-way hash function of the plaintext data Raft, Na, Nft using the key Ka. An 
exemplary notation for the message digest Dra is 
<Raft, Na,Nft>Ka. 

By including more than one nonce in the response message digest Dra, the digest is ensured 
to be distinct from any message digest Da created in the forward direction by client node A 
14. Thus, any intruding process that captures and retains a message digest Da in the forward 
direction cannot use that message digest to extract the session key from the response message 
digest Dra. 

Server node S 1 8 generates (step 128) a session key, Kab 9 which could be used by 
client node A 14, for example, to preserve data integrity or with encryption to preserve data 
confidentiality when communicating with intermediate node B 22. Server node S 1 8 next 
encodes (step 132) the session key Kaft to produce encoded session key enKaft. In one 
embodiment, the encoded session key Kaft is generated by a bit-wise exclusive-OR (XOR) of 
the two bit strings. That is, the session key Kaft is XOR'd with the message digest Dra: 

enKaft = (Kaft XOR <Rab, Na, Nft>Ka). 

In step 136, server node S 18 combines enKaft with the plaintext response message 
Raft. In one embodiment, this is accomplished by appending enKaft to the end of Ra. The 
resulting plaintext is 

(Raft, Na, Nft, enKaft), 
which expands to 

(Raft, Na, Nft, (Kab XOR <Raft, Na, Nft>Ka)). 

Because client node A 14 is the last node in the chain of nodes to receive a response 
from server node S 1 8, the RPNSEa 21 does not contain a response to a subsequent node. 
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Accordingly, the next step in the process of generating RPNSEa 21 is to generate (step 144) a 
sealed version of the plaintext data Rab, Na, NZ>, enKab. In one embodiment, computing a 
one-way hash function of the plaintext data produced in step 136, namely Rab, Na, N6, 
enKafc, using the session key Kab, produces the sealed version. As before, other sealing 
methods can be used. 

Server node S 18 completes the response directed to client node A 14 by combining 
(step 148) the sealed version produced in step 144 with the plaintext produced in step 136. 
The resulting response to client node A 14, RPNSEa 21, can be expressed as: 

(Rab, Na, N6, enKa&)> <Rab, Na, Nfr, enKjab>Kab 
Generating RPNSEfr 

Server node S 18 generates (step 120) plaintext intended for intermediate node B 22. 
The plaintext includes a response message Rba and one or more nonces. Like RPNSEa 21, 
the nonces in RPNSE6 20 can be Na and N6. Rba includes the identities of the two nodes 
for which an enclosed session key can be used for conducting secure communications. An 
exemplary notation for Rba is (B, A). In one embodiment, server node S 18 concatenates the 
nonces to the end of the response message Rba, which can be expressed as: 

(Rba, Na). 

In step 124, server node S 18 generates a sealed version of the plaintext data Rba, N6, 
Na. In one embodiment, the sealed version includes a response message digest Drba. Server 
node S 1 8 produces Drba by computing a one-way hash function of the data Rba 9 NZ>, Na 
using the key KA shared exclusively with intermediate node B 22. An exemplary notation for 
the response message digest, Drba, is 

<Rba, NZ>, Na >K*. 
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Server node S 18 generates (step 128) a session key, Kba, which intermediate node B 
22 can use, for example, with encryption to encode communications with client node A 14. 
In one embodiment, the session key Kba has the same value as the session key Kab. 
Accordingly, intermediate node B 22 can use Kba to decode communications encoded by 
client node A 14 using Kab, and client node A 14 can use Kab to decode communications 
encoded by intermediate node B 22 using Kba. Server node S 18 next encodes (step 132) the 
session key Kba to form encoded session key enK&a. In one embodiment, the encoded 
session key Kba is generated by exclusive-ORing the session key Kba with the response 
message digest Drba, i.e., 

enKfoz = (Kba XOR <Rba, Ni, Na>KZ>). 

In step 136, server node S 18 combines enK£a with the plaintext response message 
Rba, for example, by appending eriKba to Rba. The resulting plaintext can be expressed as: 

(R6a,N£,Na,enK&a), 
which expands to 

(Rba, N2>, Na, (Kba XOR <Rba, Nb, Na>K2>)). 

Because intermediate node B 22 is an intermediate node in the chain of nodes, the 
response directed to intermediate node B 22 includes the response to a subsequent node, here 
client node A 14. Server node S 18 combines (step 140) the response to client node A 14, 
RPNSEa 21, with the plaintext produced in step 136. The plaintext result of step 140 can be 
expressed as: 

(Rba, N6, No, enKta, RPNSEa). 

A sealed version of this plaintext is generated (step 144), for example, by computing a 
one-way hash function of the plaintext data components produced in step 140 using the 
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session key Kba. The sealed version can be expressed as <Rba t No, Na, enKoa, 
RPNSEa>Koa. Server node S 18 combines (step 148) the sealed version produced in step 
144 with the plaintext produced in step 140. The result can be expressed as: 

(Rba, lib, Na, enKoa, RPNSEa), < Rba, Nfr, Na, enKoa, RPNSEa>KZ>a. 

Being an intermediate node, intermediate node B 22 communicates with neighboring 
nodes A and C, 14 and 26, respectfully. Intermediate node B 22, therefore, requires a session 
key to communicate securely with client node A 14 and another session key to communicate 
securely with intermediate node C 26. As described above, the session key for 
communicating with client node A 14 is YLba. By repeating steps 120 through 136, server 
node S 1 8 includes (step 152) a second session key, Kbc, in the response so that intermediate 
node B 22 can securely communicate with intermediate node C 26. The result of repeating 
steps 120 through 136 with respect to YJbc is plaintext that can be expressed as: 

(Rbc, No, Nc, (Kbc XOR <Rbc, No, NoKi)), 
where (Kbc XOR <Rbc, No, Nc>Kb) is the encoded session key Kbc (hereafter enKoc); 
where <Rbc, No, NoKo is the message digest Dr&c of plaintext data Kbc, No, Nc using the 
shared key Kb; where No and Nc are nonces that are the same as those nonces No and Nc 
received by server node S 18 in the RQSTc 17; and where Rbc is a response message directed 
to intermediate node B 22 containing the identities of the nodes, here B and C, for which the 
session key Kbc is intended to provide secure communication. 

In step 156, server node S 18 combines the plaintext produced by step 152, namely 
(Rbc, N6, Nc, enKic), with the result of step 148, namely (Rba, N&, Na, enKta, RPNSEa), 
<Rba, No, Na, enK&a, RPNSEa> Kba, to produce a plaintext result that can be expressed as: 
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(RZ>c, N6, Nc, enKftc, RZ>a, NZ>, Na, enKfta, RPNSEa, <R£a, N£, Na, enK£a, 
RPNSEa>K6a), 

In step 160, server node S 18 completes the response, RPNSEfe 20, by repeating steps 
140 and 144 with respect to the second session key, Kbc. The resulting response RPNSE6 20 
can be expressed as: 

(Ri>c, N6, Nc, enK£c, Ri>a, NZ>, Na, enK&a, RPNSEa, <R&a, N6, Na, enKia, 

RPNSEa>K6a), <Rbc 9 Nft, Nc, enKAc, Rfca, NZ>, Na, enK*a, RPNSEa, <Rba, N6, Na, 

enK&a, RPNSEa>Kfca>K*c. 
Generating RPNSEc 

To generate RPNSEc, the process returns to step 120. Server node S 1 8 generates 
plaintext and a sealed version of the plaintext that can include a response message Rcb and 
one or more nonces. The plaintext can include nonces Nft and Nc, which are the same 
nonces, N6 and Nc, sent to server node S 1 8 in the request RQSTc 1 7. RcZ> includes the 
identities of the two nodes for which the session key is intended, here intermediate nodes B 
and C, 22 and 26, respectively. An exemplary notation for Rcb is (C, B). In one 
embodiment, server node S 18 concatenates the nonces to the response message RcZ>, which 
can be expressed as: 

(Rc*,Nc,N6). 

In step 124, server node S 18 generates a sealed copy of the plaintext data 
components Rcb, Nc, and Nfe. The sealed copy can include a message digest, Drc, produced 
by computing a one-way hash function of the data components Rcb 9 Nc, and N£? using the 
key Kc shared exclusively with server node S 1 8. An exemplary notation for the message 
digest Drc is 
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<Rc&,Nc,N£>Kc. 

In step 128, server node S 18 generates a session key, Kcb, which intermediate node 
C 26 can use, for example, with encryption to encode communications with intermediate 
node B 22 so as to preserve data confidentiality. The session key Kcb has the same value as 
the session key Kbc. Accordingly, intermediate node C 26 can use Kcb to decode 
communications encoded by intermediate node B 22 using Kbc, and intermediate node B 22 
can use Kbc to decode communications encoded by intermediate node C 26 using Kcb. 

Server node S 18 encodes the session key Kcb to produce an encoded session key 
enKcb (step 1 32). In one embodiment, eriKcb is generated by exclusive-ORing (XOR) the 
session key Kcb with the message digest Drc, i.e., 

eriKcb = (Kcb XOR <Rcb, Nc, N£»Kc). 

In step 136, server node S 18 combines eriKcb with the plaintext response message 
Rcb, for example, by appending enKc& to Rcb to produce the following plaintext: 
(Rc6,Nc,N6,enKc&). 

Because intermediate node C 26 is an intermediate node in the chain of nodes, the 
response directed to intermediate node C 26 includes the response to a subsequent node, here 
intermediate node B 22. Server node S 18 combines (step 140) the response to intermediate 
node B 22, RPNSE& 20, with the plaintext produced in step 136. The plaintext result of step 
140 can be expressed as: 

(Rcb, Nc, N6, eriKcb, RPNSEfr). 

In step 144, a sealed version of this plaintext is generated, for example, by computing 
a one-way hash function of the plaintext data produced in step 140, namely Rcb, Nc, Nfc, 
enKcfc, and RPNSE6, using the session key Kcb. The resulting sealed version is: 
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<Rcb, Nc, Kb, enKcb, RPNSE£> Kcb. 

In one embodiment, the last node in the chain before server node S 18 requires only one 
session key. Accordingly, in step 148, server node S 18 can complete the response RPNSEc 19 by 
combining the sealed version produced in step 144 with the plaintext produced in step 136. 
Alternatively, intermediate node C 26, as an intermediate node, can require another session key for 
communicating with server node S 18. In such an embodiment, the generation of RPNSEc 19 
continues by encapsulating a second session key in a similar manner as used to include a second 
session key in RPNSEfc 20 described above. 

When intermediate node C 26 does not require two session keys, the final response, 
RPNSEc, passing from server node S 1 8 to intermediate node C 26 can be expressed as: 

(Red, Nc, Nft, enKcb, RPNSE6), <Rcb, Nc, N£, criKcb, RPNSEfc>Kc£. 
The response to each node X requesting a session key generalizes to: 

RPNSEx = (..., enKxjr+7, (..., enKx.x-7, RPNSEx-7), <..., enKxjc-7, RPNSEx- 1>Kxjc-7), 

<..., enKx_r+7, (..., enKx.x-7, ... RPNSEx-7), <..., enKxjc-7, RPNSEx-l> Kxjc- 

7>Kx.x+7, 

where X is the identity of the node targeted for the RPNSEx, X+l is the identity of the neighboring 
node toward the server 18, and X-l is the identity of the neighboring node away from the server 18. 
Note that the generalized form applies to intermediate nodes requiring two session keys, and that in 
some implementations the first and last nodes in the chain (e.g., client node A 14 and intermediate 
node C 26) may receive only one session key. 
Protocol for Processing Server Resp nn^ 

Fig. 8 shows an exemplary process by a full response from server node S 1 8 is 
processed by each node in a chain of nodes to obtain individual session keys. 
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Evaluating RPNSEc 

For illustration purposes, intermediate node C 26 is the first node in the chain of nodes 
to receive the response, here RPNSEc 19, which has been generated and issued by server node 
S 18 (step 164). As described above, RPNSEc 19 includes a plaintext portion and a sealed 
portion. The plaintext portion includes Rcb, Nc, N6, enKcft, and the next embedded response 
RPNSEfc 20. Intermediate node C 26 cannot decipher any of the session keys sealed within 
RPNSEfc 20 because RPNSE& is sealed with key Kb. 

Because intermediate node C 26 has the key Kc, intermediate node C 26 can generate 
(step 168) the message digest Drc from the plaintext components Rcb, Nc, Ni> included in the 
response RPNSEc 19. Intermediate node C 26 then uses the message digest Drc to extract 
the session key Kcb from the plaintext by performing a bit-wise exclusive-OR operation 
using enKcfc and the message digest Drc (step 172). This exclusive-OR operation recovers 
Kcb because exclusive ORing twice in succession with the same value reproduces the 
original value. For example: 

1) . Kc£XORDrc = enKcZ>; 

2) . enKc£> XOR Drc = Kcb. 

Once intermediate node C 26 obtains Kcb, intermediate node C 26 uses (step 176) 
Kcb to extract the data within the sealed portion of RPNSEc 19. The extracted data include 
the embedded response RPNSE& 20. Intermediate node C 26 then compares (step 180) the 
extracted data with the plaintext data. 

If the extracted data do not match the plaintext data, RPNSEc 19 is invalid. If instead 
the extracted data match the plaintext data, intermediate node C 26 knows that server node S 
18 is the sender of the RPNSEc 19 because only server node S 18 and intermediate node C 26 
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know the key Kc used to produce the encoded session key enKcb. Intermediate node C 26 
also knows that the data Rcb, Nc, Nb, and RPNSE6 are unaltered during the transmission to 
intermediate node C 26 from server node S 1 8. Further, intermediate node C 26 can compare 
the nonce Nc received in RPNSEc 19 with the nonce that intermediate node C 26 stored upon 
sending RQSTc 17 to server node S 18. A match indicates the RPNSEc 19 is a current 
response to an outstanding request. Intermediate node C 26 can now use the extracted 
session key Kcb to encode subsequent communications with intermediate node B 22. If 
RPNSEc 1 9 is valid, intermediate node C 26 transmits (step 1 84) the embedded response, 
RPNSE6 20, to intermediate node B 22. 
Evaluating RPNSEfe 

Intermediate node B 22 receives (step 164) RPNSE6 20, which also includes plaintext 
and sealed data. As described above, plaintext portion of RPNSE6 20 is 

(R2>c, Nfc, Nc, eriKbc, Rba, N6, No, evKba, RPNSEc), <Kba, Nb, Na, enKfoj, 
RPNSE*>Kfca. 

Because intermediate node B 22 has the key Kb, intermediate node B 22 can generate 
(step 168) the message digests Drbc and Drba from the plaintext components included in the 
response RPNSE& 20. Intermediate node B 22 uses (step 172) the message digest Drbc to 
extract the session key Kbc by exclusive-ORing enKAc with the message digest Drbc. 
Likewise, intermediate node B 22 uses the message digest Drba to extract the session key 
Kba by exclusive-ORing enKba with the message digest Drba. Upon extracting (step 1 76) 
Kbc, intermediate node B 22 uses Kbc to extract the data within the sealed version of 
RPNSE6 20. A portion of these extracted data requires further extraction because the session 
key Kba also seals that portion. Intermediate node B 22 then uses Kba to extract the data 
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within this portion, one of such data being the embedded response RPNSEa. Intermediate 
node B 22 then compares (step 180) the extracted data with the plaintext data. 

Again, if the extracted data do not match the plaintext data, RPNSE6 20 is invalid. If 
instead the extracted data match the plaintext data, intermediate node B 22 knows that server 
node S 1 8 is the generator of the RPNSEfc 20 because only intermediate node B 22 and server 
node S 1 8 has the key Kb used to create the encoded session keys enK&c and enK&a. 
Because of the match, intermediate node B 22 also knows that the data Rbc, Rba, Nc, N6, 
Na, and RPNSEa are unaltered during the transmission to intermediate node B 22 from 
server node S 1 8. Further, intermediate node B 22 can compare the nonce Nfe received in 
RPNSE6 20 with the nonce that intermediate node B 22 stored upon sending RQST6 16 to 
intermediate node C 26. A match indicates the RPNSE6 20 is a current response to an 
outstanding request. Intermediate node B 22 can now use the extracted session key Kba to 
encode subsequent communications with client node A 14 and the extracted session key Kbc 
to encode subsequent communications with intermediate node C 26. If RPNSE6 20 is valid, 
intermediate node B 22 transmits (step 184) the embedded response, RPNSEa 21, to client 

node A 14. 
Evaluatinp RPNSEa 

Upon receiving RPNSEa 21, client node A 14 evaluates RPNSEa 21 in a manner 
similar to the evaluation of RPNSEc 19 by intermediate node C 26. Client node A 14 receives 
(step 164) RPNSEa 21 from intermediate node B 22. RPNSEa 21 includes plaintext and 
sealed data. As described above, the plaintext portion of RPNSEa 21 is 

(Rao, Na, Nfr, enKao)- 
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Because client node A 14 has the key Ka, client node A 14 can generate (step 168) 
the message digest Dra from the plaintext components Rab, Na, No included in the response 
RPNSEa 21 . Client node A 14 then uses (step 172) the message digest Dra to extract the 
session key Kab from the plaintext by exclusive-ORing enKao with the message digest Dra. 
After obtaining the session key YLab, client node A 14 uses (step 176) ¥Lab to extract the data 
within the sealed portion of RPNSEa 21. Client node A 14 then compares (step 180) the 
extracted data with the plaintext data. Again, if the extracted data do not match the plaintext 
data, client node A 14 can ignore RPNSEa 21 because RPNSEa 21 is invalid. If the 
extracted data match the plaintext data, client node A 14 knows that server node S 18 is the 
generator of the RPNSEa 21 because only server node S 18 and client node A 14 have the 
key Ka used to create the encoded session key enKafc. Client node A 14 also knows that the 
data Rab, Na, NZ>, and RPNSEa are unaltered during the transmission to client node A 14 
from server node S 1 8. 

Further, client node A 14 can compare the nonce Na received in RPNSEa 21 with the 
nonce that client node A 14 stored upon sending RQSTa 15 to intermediate node B 22. A 
match indicates the RPNSEa 21 is a current response to an outstanding request. 
Accordingly, client node A 14 can use the extracted session key Kab to encode subsequent 
communications with intermediate node B 22. At client node A 14, the propagation of 
responses completes. With one round-trip traversal of the forward and reverse paths, each 
node in a chain of nodes has securely requested and securely received at least one session key 
from the server node S 1 8. 

While the invention has been shown and described with reference to specific 
preferred embodiments, it should be understood by those skilled in the art that various 
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changes in form and detail may be made without departing from the inventive concepts 
disclosed. 
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CLAIMS 

1 . In a network including a first node, a second node, and a third node, a method for 
securely delivering digital information to the first node from the third node by way of the 
second node, the method comprising the steps of: 

receiving a request at the third node from the first node; 

generating digital information in response to the request; 

operating on the request and the digital information to produce a first data structure, 
the first data structure including a representation of the digital information; 

operating on the request and the first data structure to produce a second data structure, 
the second data structure including the first data structure; and 

transmitting the second data structure to the second node. 

2. The method of claim 1 wherein the digital information is a session key for the first 
node to use in communications with the second node. 

3. The method of claim 2 further comprising the step of encoding the session key using 
a key shared exclusively with the first node to conceal the session key within the first data 
structure. 

4. The method of claim 2 further comprising the step of sealing a portion of the first data 
structure using the session key. 

5. The method of claim 4 further comprising the steps of: 
receiving the first data structure from the second node; 
decoding the encoded session key using the shared key; 
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extracting data from the sealed portion of the first data structure using the decoded 
session key; and 

using the extracted data (1) to authenticate that the session key originated from the 
third node, (2) to determine that the session key is unaltered during transmission from the 
third node, and (3) to determine that the first data structure is a current response from the 
third node to the request from the first node. 

6. The method of claim 2 further comprising the steps of: 

generating a second session key for the second node to use in communications with 
the first node; 

sealing a portion of the second data structure containing the first data structure using 
the second session key. 

7. The method of claim 6 further comprising the steps of: 

encoding the second session key using a key shared exclusively with the second node; 

and 

including the encoded second session key within the second data structure. 

8. The method of claim 2 further comprising the steps of: 

extracting the first data structure from the second data structure at the second node; 
transmitting the first data structure to the first node from the second node; and 
extracting the session key from the first data structure at the first node. 

9. The method of claim 8 wherein the session key is a first session key and the second 
data structure includes a second session key and further comprising the step of: 
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extracting the second session key from the second data structure at the second node, 
and wherein the first and second session keys provide secure communication between the 
first node and the second node. 

10. The method of claim 1 wherein the second node is a first intermediate node and the 
network includes a second intermediate node in a communication path between the first 
intermediate node and the third node, and further comprising the steps: 

operating on the request and the second data structure to generate a third data 
structure, the third data structure including the second data structure; 

transmitting the third data structure to the second intermediate node; and 
extracting the second data structure at the second intermediate node for transmission 
to the first intermediate node. 

1 1 . The method of claim 2 wherein the step of generating the first data structure includes: 
generating plaintext; 
encoding the session key; 

generating a digest of a combination of the plaintext and the encoded session key; and 
combining the plaintext, the encoded session key, and the digest to produce the first 
data structure. 

12. The method of claim 1 1 wherein the step of generating the digest includes applying a 
one-way hash function using the session key to the combination of the plaintext and the 
encoded session key. 
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13. The method of claim 1 1 wherein the step of generating the digest includes applying 
an encryption algorithm using the session key to the combination of the plaintext message 
and the encoded session key. 

14. The method of claim 1 1 wherein the step of encoding the session key includes: 
generating a digest of the plaintext; and 

exclusive-ORing the session key with the digest of the plaintext to produce the 
encoded session key. 

15. The method of claim 1 1 wherein the plaintext includes a first nonce associated with 
the first node and a second nonce associated with the second node. 

16. The method of claim 2 wherein the step of generating the second data structure 
includes: 

generating plaintext; 
generating a second session key; 
encoding the second session key; 

generating a digest of a combination of the plaintext, the encoded second session key, 
and the first data structure; and 

combining the plaintext, the encoded second session key, the first data structure, and 
the digest to produce the second data structure. 

1 7. The method of claim 2 further comprising the step of generating the request 
including: 

generating a first plaintext at the first node; 
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generating a first digest of the first plaintext at the first node; 

transmitting a first combination of the first plaintext and the first digest from the first 
node to the second node; 

generating a second plaintext at the second node; 

generating a second digest of a second combination of the second plaintext and the 
first combination of the first plaintext and the first digest; and 

combining the second plaintext and the second digest to produce the request. 

18. In a network including a client node and an authentication server node, a method for 
securely delivering a session key to the client node from the authentication server node in 
response to a request from the client node, the method comprising the steps of: 

sealing plaintext using the session key; 

encoding the session key using a key shared with the client node; and 
transmitting a data structure to the client node that includes the encoded session key 
and the sealed plaintext. 

1 9. The method of claim 1 8 fiirther comprising the steps of: 
receiving the data structure; 

decoding the encoded session key using the shared key; 
extracting the sealed plaintext using the decoded session key; and 
using the extracted plaintext to authenticate that the session key originated from the 
authentication server. 
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20. The method of claim 1 9, further comprising the step of determining from the 
extracted plaintext that the decoded session key is unaltered during transmission from the 
authentication server. 

2 1 . The method claim 1 9, further comprising the step of detennining from the extracted 
plaintext that the data structure is a current response from the authentication server to the 
request from the client node. 

22. The method of claim 1 8 wherein the data structure is a first data structure and the 
network includes an intermediate node in a communication path between the authentication 
server node and the client node, and further comprising the steps: 

operating on the request and the first data structure to generate a second data 
structure, the second data structure including the first data structure; and 

transmitting the second data structure to the intermediate node for extracting the first 
data structure at the intermediate node and for transmitting the extracted first data structure to 
the client node. 

23. A system for securely distributing a session key by way of a network, the network 
including a first node transmitting a request to obtain the session key and a second node in 
communication with the first node, the system comprising: 

a third node in communication with the second node and receiving the request by way 
of the second node, the third node including: 

a processor generating (1) a first data structure by operating on the request and the 
session key, the first data structure including a representation of the session key, and (2) 
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generating a second data structure by operating on the request and the first data structure, the 
second data structure including the first data structure; and 

a network interface coupled to the processor for transmitting the second data structure 
to the second node over the network. 

24. A method for securely delivering digital information in a network, substantially as 
hereinbefore described with reference to the accompanying drawings. 

25. A method for securely delivering a session key to a client node from an authentication 
server node in a network, substantially as hereinbefore described with reference to the 
accompanying drawings. 

26. A system for securely distributing a session key by way of a network, substantially as 
hereinbefore described with reference to the accompanying drawings. 
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